Microsoft treibt die Entwicklung von Azure mit hoher Geschwindigkeit voran. So gut wie jeden Monat werden neue Ankündigungen veröffentlicht. Selbst intensive Nutzer sind herausgefordert, wenn sie an allen Fronten Bescheid wissen wollen – von Azure-Anfängern gar nicht zu sprechen. Nicht gerade dienlich war dabei die bisherige Vorgehensweise, alle Features quasi gleichwertig nebeneinander zu positionieren. Da gab es Websites, virtuelle Maschinen und SQL-Datenbanken gleichgestellt mit HDInsight, Media-Services und Machine Learning. Welche Komponenten gemeinsam Sinn ergeben und zusammenspielen, war schwer ersichtlich; schon gar nicht aber konnten verschiedene Azure-Services innerhalb derselben Instanz betrieben werden. Wer beispielsweise einen Mobile-Service und eine Website betrieben hat, musste getrennt dafür zahlen.

Mit den neu vorgestellten App-Services wird versucht, vier zusammenhängende Dienste unter einem gemeinsamen Namen anzubieten. Eine Grundbedingung aus der Marketingabteilung war offensichtlich die Verwendung des Worts App im Namen: So wurden die Websites zu Web-Apps, die Mobile-Services zu Mobile-Apps und zwei Neuzugänge auf Logic-App bzw. API-App getauft. Jeder dieser Services kann weiterhin separat und unabhängig genutzt werden – doch es gibt eine Story, wie die genannten Komponenten zusammenspielen können, und damit vielleicht einen leichteren Einstieg in die Welt von Microsoft Azure.

Web-Apps

Aber der Reihe nach. Am wenigsten spektakulär verlief die Ankündigung der App-Services für die Nutzer von Azure-Websites. Die Umbenennung blieb die einzige direkt sichtbare Auswirkung, Web-Apps können nicht mehr und nicht weniger als die bisherigen Websites. Sämtliche bereits deployten Anwendungen waren vom ersten Tag an unter dem neuen Begriff sichtbar, kein Migrationsaufwand, keine Probleme. Der Mehrwert kommt erst durch die optionale Nutzung der weiteren Services, die in einem bestehenden Webcontainer ohne zusätzliche Kosten betrieben werden können.

Mobile-Apps

Unter dem Namen Mobile-Services sind mehrere Angebote vereint, die das Entwickeln von Apps erleichtern konnten: Ein REST-basierter Zugriff auf Daten, das Senden von Push Notifications quer durch alle Plattformen oder die Authentifizierung mittels Providern wie Facebook, Twitter oder ein Microsoft-Account. Zum Teil ist es auch möglich, die Services durch eigenen Backend-Code anzupassen: Die REST-Datenschnittstelle stellt zum Beispiel Erweiterungspunkte zur Verfügung, die ähnlich wie Datenbank-Trigger genutzt werden können. Als Programmiersprachen für das Backend stehen Node.js oder .NET zur Verfügung. Die gesamte Funktionalität ist über eine REST-basierte Schnittstelle zu konsumieren, es gibt aber SDKs, um den Zugriff aus Windows Phone, iOS und Android zu erleichtern.

Im neuen App-Services-Paket tauchen nun große Teile der Funktionalität unter dem Namen Mobile-Apps wieder auf – aber nicht ganz so reibungslos und unverändert wie bei den zuvor genannten Websites. Erstes Anzeichen: Bisherige Mobile-Services wurden nicht automatisch migriert, im alten Azure-Portal befinden sich weiterhin alle Instanzen unter unverändertem Namen (eine Anleitung zur Migration befindet sich hier). Mit ein Grund kann sein, dass als Sprache für das Backend in Mobile-Apps vorerst nur .NET zur Verfügung steht – die in den Mobile-Service gebräuchlichere Node.js-Variante fehlt noch. Der für das Backend notwendige Code kann nun aber gemeinsam mit der Web-App ohne zusätzliche Kosten im selben Container gehostet werden – inklusive Auto-Scaling, Traffic-Manager-Support oder Deployment-Vorteilen wie Continuous Integration und Staging Deployments. Als weitere Neuerung sind Verbindungen zu On-Premise-Datenbanken möglich, ein eingerichtetes virtuelles Netzwerk mit Point-to-Site-VPN wird vorausgesetzt. Wer vor der Aufgabe steht, eine mobile App für iOS, Android oder Windows Phone zu entwickeln und dafür Push Notifications, Authentifizierung oder (On-Premise)-Datenzugriff benötigt, sollte sich Mobile-Apps ansehen.

Es ist anzunehmen, dass die bisherigen Mobile-Services über kurz oder lang komplett durch die neuen Mobile-Apps ersetzt werden, für den Moment gibt es allerdings beide Varianten parallel.

API-Apps

Kommen wir zu den Neuerungen: API-Apps sind brandneu und fügen der Azure-Palette wieder einen deutlichen Mehrwert hinzu. Im Wesentlichen handelt es sich dabei um Web-API-Projekte, die um Metadaten und Authentifizierung angereichert sind.

Als Format für diese Metadaten kommt – ganz im Sinne des aktuellen Microsoft-Mindsets – keine hauseigene, proprietäre Lösung, sondern ein bewährtes, existierendes Open-Source-Projekt namens Swagger zum Einsatz. Eine Swagger-Definition besteht aus einer Beschreibung der einzelnen Methoden und deren Parameter in einem spezifizierten JSON-Format. Alter Wein in neuen Schläuchen? CORBA? WSDL? Im Prinzip ja. Das Swagger-Format ist aber sehr schlank und erfordert keine Änderung von bestehenden APIs – theoretisch könnte die Swagger-Definition sogar von jemand anderem als dem API-Hersteller geschrieben werden. Die größten Vorteile, die Metadaten mit sich bringen, sind schnell beschrieben: automatische Dokumentation und Client-SDK-Generierung.

Hello, API-App

Abb. 1: Erstellen eines Azure-API-App-Projekts in Visual Studio

Wie sieht das in der Praxis aus? Im neuesten Azure-SDK (März: 2.5.1) sind die App-Services bereits integriert. Beim Erstellen einer neuen ASP.NET-Webapplikation steht als Template „Azure-API-App-(Preview)“ zur Verfügung, dadurch wird ein Web-API-Projekt mit einigen zusätzlichen Referenzen erstellt (Abb. 1). Sollten Sie ein bestehendes ASP.NET-Web-API-Projekt verwenden wollen, klicken Sie mit der rechten Maustaste auf das Projekt und anschließend auf ADD | Azure API App SDK. Sie werden anschließend gefragt, ob die Swagger-Metadaten automatisch erstellt werden sollen (Abb. 2, die Antwort lautet: Ja).

Abb. 2: Metadatengenerierung oder -auswahl

Das Erstellen der Web-API-Controller unterscheidet sich nicht von der gewohnten Art und Weise; wie bisher leiten Sie von ApiController ab, erstellen darin Actions und verwenden ggf. Routing-Attribute (Listing 1). Einziger Hinweis: Ein Bug verhindert (zumindest bis April) das Überladen von Action-Methoden. Vermeiden Sie also beispielsweise zwei Get-Methoden, die sich nur durch einen Parameter unterscheiden – das Azure-Portal hat ansonsten Probleme beim Abrufen der Metadaten.

public class WishlistController : ApiController
{
  public string Get()
  {
    return "Hello API App!";
  }

  public async Task Post(WishRequest request)
  {
    // store data
  }
}

Was Ihr Web-API nun zu einer API-App macht, sind die Metadaten. Die automatische Metadatengenerierung sollte aktiviert sein; erstes Erkennungsmerkmal ist die Datei apiapp.json im Hauptverzeichnis mit einigen allgemeinen Metadaten. Wichtiger ist die Klasse SwaggerConfig im Unterordner App_Start. Hier können Sie in die Generierung der Metadaten eingreifen und beispielsweise festlegen, ob auch das Swagger-UI bereitgestellt werden soll: ein interaktives UI zum Testen des API.

Wenn Sie die Anwendung ausführen, können Sie den Erfolg unmittelbar testen: Unter http://localhost:<port>/swagger/docs/v1 können Sie das Swagger-JSON-Format ansehen, unter /swagger erscheint das UI (Abb. 3).

Abb. 3: Swagger-UI

Damit steht dem Veröffentlichen nichts mehr im Weg: Auch der Publish-Dialog (rechte Maustaste auf das Projekt | Publish) kennt bereits Microsoft-Azure-API-Apps als Ziel. Über den Dialog kann eine bestehende API-App ausgewählt oder eine neue erstellt werden. Beim ersten Mal wird auch die App in Azure erstellt, teilweise ist anschließend ein zweites beherztes Anstoßen des Publish-Vorgangs erforderlich.

Wenn alles erfolgreich war, sehen Sie die neu angelegte API-App im Preview-Azure-Portal. Auch dort können Sie die Metadaten („API-Definition“) abrufen und überprüfen, ob alles geklappt hat (Abb. 4).

Abb. 4: Swagger-Metadaten im Azure Portal

Nun ist die Zeit der Ernte gekommen: Aufgrund der Metadaten können Sie sich ein passendes Client-SDK generieren lassen – HttpClient-Aufrufe und manuelles Parsen von Response-Nachrichten gehören der Vergangenheit an. Egal ob in einer Konsolenanwendung oder in einer Windows-Phone-App: Klicken Sie beim Projekt auf Add | Azure API App Client und wählen Sie die gerade bereitgestellte API-App aus. Auf Basis der Swagger-Definition werden entsprechende Interfaces und Klassen zum Zugriff auf das API zur Verfügung gestellt – übrigens nicht nur für .NET, sondern auch für Node.js, Java, PHP und Python. In Listing 2 sehen Sie, wie einfach die zuvor erstellten Get- und Post-Requests nun in einer Windows-Phone-App aufgerufen werden können.

IMySuperWishlistApi api = new MySuperWishlistApi();
var getResponse = await api.Wishlist.GetAsync();

var wish = new WishRequest()
{
  UserName = "[email protected]",
  Wish = "An API that works"
};

await api.Wishlist.PostAsync(wish);

Neben den Metadaten kann auch Authentifizierung ein Grund für die Verwendung von API-Apps sein. Derzeit sind drei verschiedene Sicherheitslevel wählbar: öffentlich, authentifiziert oder intern. Letzteres ermöglicht einen Aufruf für alle Services innerhalb der gleichen Ressource, fällt die Wahl hingegen auf authentifiziert, muss ein Authentifizierungsprovider (Microsoft-Account, Facebook etc.) konfiguriert werden. Die Einstellungen finden Sie im neuen Azure-Portal bei der API-App unter Settings | Application settings bzw. Authentication, eine genaue Anleitung hier. Authentifizierung ohne ein OAuth-Buch lesen zu müssen und Tokens zu parsen – ein verlockendes Angebot.

Fast schon zur Gewohnheit gehört, dass Sie mittels Remote-Debugging den laufenden Service mit Visual Studio debuggen können. Gerade für die Fehlerfindung zu Beginn ein äußerst hilfreicher Wegbegleiter.

Logic-Apps

Sie haben gesehen, wie einfach es ist, ein eigenes API inklusive Metadaten bereitzustellen. Zusätzlich gibt es bereits eine unglaubliche Vielzahl von Services – teilweise kostenlos, teilweise kostenpflichtig – die auf ihre Verwendung warten: Dropbox, OneNote, Facebook, Twitter, Yammer, Slack, Twilio etc.

Diese Vielzahl an APIs, die zusätzlich um Metadaten angereichert werden, hat vermutlich zur Idee der vierten Komponente geführt: Logic-Apps. Diese zumindest grafisch auffälligste Neuerung weckt wieder die Idee, dass Softwareentwicklung irgendwann nur mehr das Zusammensetzen fertiger Bausteine sein könnte (was ich weder hoffe, noch glaube). Mithilfe eines grafischen Editors können Sie Services aneinanderreihen und die Ergebnisse des einen Service wieder als Eingabeparameter für den nächsten Service verwenden.

Ein Beispiel: Prüfen Sie alle fünf Minuten, ob es aktuelle Twitter-Nachrichten zu einem bestimmten Hashtag gibt und übergeben Sie das Ergebnis an Ihr API. Überprüfen Sie Ihren POP3-Posteingang nach neuen Mails mit dem Betreff „Wichtig“ und senden Sie in diesem Fall eine SMS an Ihr Handy. Fragen Sie Ihren Service in regelmäßigen Abständen nach Neuigkeiten und posten Sie diese gleichzeitig auf Twitter, Yammer und Facebook.

Die gute Nachricht: Alle erwähnten Services sind bereits jetzt im Azure-Marketplace zu finden, alle genannten Beispiele könnten schon jetzt als Logic-App umgesetzt werden. Die Vielfalt erhöht den Spaßfaktor deutlich: Irgendeinen Service findet man immer, der unbedingt noch eingebaut werden muss.

In Abbildung 5 sehen Sie beispielsweise einen POP3-Connector, der einmal pro Minute den Posteingang überprüft und beim Eintreffen einer E-Mail unsere zuvor erstellte API-App aufruft. Im dritten Schritt wird Twilio verwendet, um den Betreff der E-Mail per SMS zu versenden.

Abb. 5: Erstellung einer Logic-App

Jeder Service kann so konfiguriert werden, dass er nur beim Erfüllen einer bestimmten Bedingung ausgeführt wird – allerdings ist die zugrunde liegende Formelsprache aktuell eher schlecht dokumentiert. Im Azure-Portal erhalten Sie detaillierte Monitoring-Reports über jede Abarbeitung: Bis hin zu den einzelnen Requests können Sie so nachverfolgen, ob Ihre Logic-App wie gewünscht funktioniert.

Fazit

Microsoft versucht, mit den App-Services ein Paket zu schnüren, das die Entwicklung von Webanwendungen und mobilen Apps vereinfachen kann. Das Gesamtpaket ist umfangreich, im Detail warten aber derart viele Möglichkeiten, dass trotz des Versuchs einer durchgängigen Story die Einarbeitungszeit beträchtlich ist. Lassen Sie sich davon nicht abschrecken, nutzen Sie, was Sie benötigen. Sie möchten eine Website hosten? Nehmen Sie Web-Apps. Sie benötigen Push Notifications oder möchten einen Login in Ihre App einbauen? Testen Sie Mobile-Apps. Möchten Sie Ihr API authentifiziert oder mit Metadaten bereitstellen? API-App. Oder möchten Sie bestehende APIs zu einem größeren Ganzen orchestrieren? Logic-App.

Viel Spaß beim Ausprobieren und Kennenlernen der Azure App Services.

Aufmacherbild: Cloud computing via Shutterstock / Urheberrecht: Stokkete